perf(prover): default the cuda table scheduler to K = num_airs - #911

The sweep record moves out of the tree to a gist linked from the PR, so
the doc comment can no longer cite scripts/profiling/table-parallelism-sweep/.

Brings in the four commits that landed since the campaign base 58160b6:
the bump guest allocator default (#869), the VRAM-pressure/R2-race fix
(#914), the cuda table scheduler K = num_airs default (#911), and the
device-only cliff recovery at R4 DEEP / comp-tree / R3 barycentric (#935).

Conflicts resolved (one file, three hunks, all the same collision):

- crypto/stark/src/prover.rs — the Stage-2 H-threading parameterized
  Round1/Round2 over the hasher, while #935 changed the same parameters
  from shared to mutable so the cliff recovery can download resident
  device data back into the host buffers. Rule: keep both — main's `&mut`
  mutability and this branch's `H` parameter. Applied at
  round_3_evaluate_polynomials_in_out_of_domain_element,
  round_4_compute_and_run_fri_on_the_deep_composition_polynomial, and
  compute_deep_composition_poly_evaluations. The recovery paths therefore
  run through the H-generic signatures; nothing is un-genericized.

Everything else merged without conflict. Checked by hand rather than
trusted to the textual merge:

- crypto/stark/src/gpu_lde.rs — the two sides are disjoint. #935 appends
  the host-download helpers and the sticky fault hooks; the H-threading
  edits sit in the tree-building and FRI-commit entries. main's one hunk
  inside threaded territory is comment-only.
- crypto/math-cuda/src/lib.rs — both sides add one `pub mod` to the same
  alphabetized list (`blake3` here, `faults` on main); both survive.
- crypto/math-cuda/src/device.rs — touched only by this branch, so #935's
  math-cuda edits (barycentric, deep, faults, merkle) do not collide.
- prover/tests/calibration.rs and prover/src/auto_storage.rs — #911 splits
  the scheduler's `k` from the storage estimate's, so both call sites move
  to `storage_estimate_parallelism()`. This branch never touched either
  file, so main's version lands whole and the RAM-vs-Disk decision is
  unmoved.
- The `table_parallelism()` call site takes main's `table_parallelism(num_airs)`,
  which clamps internally to the same range this branch clamped by hand.

Carries origin/main (cf3b1e9) onto the flip branch: the bump guest allocator
default (#869), the VRAM-pressure/R2-race fix (#914), the cuda table scheduler
K = num_airs default (#911), and the device-only cliff recovery at R4 DEEP /
comp-tree / R3 barycentric (#935).

No conflicts. Both of the resolutions made when main met this campaign's tree
were already settled one branch down and arrive whole:

- `crypto/stark/src/prover.rs` — Round1/Round2 carry both main's `&mut` and the
  campaign's `H` parameter, so #935's cliff recovery runs through the H-generic
  signatures.
- `crypto/stark/src/prover.rs` — the device-only main-LDE recovery matches
  `MainLdeSlot` exhaustively: `Retained` downloads off the resident handle,
  `Dropped` (RecomputeLde) needs nothing because the fused task rebuilds from the
  host trace.

The flip's own collision surface stayed clear: the renamed alias layer
(`DefaultStarkHash`, `DefaultStarkTranscript`) and the `assert_keccak_backend`
guard over the cuda fork are untouched by main's gpu_lde edits, and the cuda
clippy pass — where this branch resolves to keccak — compiles clean.

Gates: stark release 287/0; crypto 72/0 on both round arms; `lfm::` 354 passed /
1 failed / 9 ignored, the same single pre-existing `fibonacci.elf` drift
exonerated in RESUME-PA-STAGE6.md §5.7, so zero delta; BLAKE3 host KAT green on
both round arms; second-source green; `make lint` clean across all five combos;
fmt clean.

The cross-version king gate against pre-merge refs stays failing by design — that
is the flip's inverted polarity (PA-PLAN §6), not a merge regression.

Carries origin/main (cf3b1e9) onto the MMCS integration branch: the bump guest
allocator default (#869), the VRAM-pressure/R2-race fix (#914), the cuda table
scheduler K = num_airs default (#911), and the device-only cliff recovery at
R4 DEEP / comp-tree / R3 barycentric (#935).

This is the branch where the two sides genuinely interleave. M-4p2 extracted the
round bodies so they take the data they use — `lde_trace`, `composition_parts`,
`rap_challenges` — instead of the whole `Round1`/`Round2`, and `multi_prove_batched`
reuses those same extractions. #935 works the other way: its recoveries write the
resident device data back into those very buffers, which is why upstream widened
the round signatures to `&mut Round1`/`&mut Round2`. Neither shape can simply win.

Resolution rule, applied to all nine hunks: **keep the extraction, move the
mutability onto the extracted parameter.** Each recovery then writes to exactly
the buffer its caller owns, and the batched path keeps sharing one implementation
with the monolithic one.

- `crypto/stark/src/prover.rs` `compute_composition_parts` — `lde_trace` becomes
  `&mut`; the R2 host-evaluator arm takes #935's recover-then-assert (replacing the
  old hard abort) against that parameter rather than `round_1_result.lde_trace`.
- `crypto/stark/src/prover.rs` `compute_composition_parts` — the `evaluate_dev`
  arm keeps the extracted `rap_challenges` and the extracted `lde_trace` in the
  `host_trace_empty` retain flag.
- `crypto/stark/src/prover.rs` `round_2_compute_composition_polynomial` — keeps the
  `CompositionParts` return, and #935's fold of the R2 device parts handle into the
  session (`set_gpu_composition_parts`) is added after the call, where
  `round_1_result` is in scope.
- `crypto/stark/src/prover.rs` `round_3_evaluate_polynomials_in_out_of_domain_element`
  — extracted `lde_trace` and `composition_parts` both become `&mut`; the R3 parts
  OOD arm takes #935's recovery against them.
- `crypto/stark/src/prover.rs` `compute_deep_composition_poly_evaluations` — same
  two parameters become `&mut`; the host DEEP loop's recovery writes through
  `composition_parts` instead of `round_2_result.lde_composition_poly_evaluations`.
- `crypto/stark/src/batched/prover.rs` — the three call sites and `deep_codeword`
  follow the widened signatures; the FRI combine closure captures `retained_parts`
  mutably. That closure is `FnOnce` and runs serially, so the capture adds no
  concurrency requirement.
- `crypto/stark/src/prover.rs` — the two `mut` bindings the split moved: the
  parts the R2 commit recovery writes now live in
  `round_2_compute_composition_polynomial` (so `computed.parts` is bound `mut`
  there), and `compute_composition_parts`'s own local is no longer mutated by
  anything, so it loses the `mut` and the `unused_mut` cfg_attr that went with it.
  Only the cuda lint pass sees either.

Both semantics are live afterwards: nothing is un-genericized, no recovery is
dropped, and the parameter each recovery writes to is the one the caller reads
next.

Gates: stark release 350/0 (RESUME-MMCS-INT.md's 349/0 plus main's new
`table_parallelism_stays_within_one_and_num_airs`); debug batched/mmcs 87/0,
exactly the recorded baseline; crypto 71+1/0 on both round arms; `make lint`
clean across all five combos; fmt clean.

`lfm::` reads 345 passed / 19 failed / 9 ignored against a recorded baseline of
349/15/9, and the merge is NOT the cause. Checked out 46798a5 — this branch's
own pre-merge tip — and ran the same suite there: 345/19/9, and the 19 failing
test names diff byte-identical against the merged tree's. The merge delta is
exactly zero; the recorded baseline is stale, drifted by the fixture/toolchain
trap already documented in the lfm fixture-drift notes. Independently, every
resolution in this merge is inside `#[cfg(feature = "cuda")]` or is a signature
mutability change, and that suite runs without cuda, so it could not have moved
those tests either way.

SEMANTIC-CONFLICT NOTE. The batched path consumes its parts on the host
immediately (`parts_builder.absorb`) and never reads the device parts handle, so
the recoveries are inert there today — `materialize_composition_parts_host`
returns true without touching anything when the evals are already populated, so
the widened signatures cost the batched path nothing and cannot trip its asserts.
The recovery is only reachable on the monolithic path. Flagged because that is a
judgement about reachability, not something a test currently pins.